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This  report  contains  a  note  written  following  a  discussion 
of  the  real  precision  problem  in  Ironman  at  the  Twente,  Bollard 
meeting  of  WG2.4  earlier  this  year.   It  also  contains  a  verbatim,  un 
unexpurgated  /ersion  of  a  written  dialog  on  exception  handling  in 
green  which  occured  at  this  conference  during  one  of  the  sessions. 


*"Thi3  work  was  supported  in  part  by  NSF  Grant  No.  MCS76-00116 
from  The  National  Sciences  Foundation.   Any  opinions,  findings,  and 
conclusions  or  recommendations  expressed  in  this  publication  are  those 
of  the  author (s)  and  do  not  necessarily  reflect  the  views  of  The 
National  Science  Foundation." 


PART  I 


IRON  MAN  REALS  AND  THE  INFAMOUS    "SQU.\RE  ROOT"  PROBLEM 


R.  DEWAR 


If  several  variables  are  declared: 


X 
Y 
Z 


REAL  (8) 
REAL  (12) 
REAL  (15) 


Then  the  question  arises  of  how  many  types  are  present;  there  are 
three  possible  answers: 

(1)   3  -  Each  separate  precision  is  a  separate  type,  regardless 
of  implementation. 

(ii)   1  -  All  precisions  are  one  type  (the  precision  is  an 
attribute)  (Ironman) . 

(iii)   2    (or  maybe  1  or  3!)  -  my  machine  was  single  precision 
up  to  9,  double  precision  up  to  18. 

We  can  also  ask  how  many  square  root  routines  are  required  (by 

overloading)  and  get  three  answers.   This  question  makes  it 

immediately  clear  that  answer  (iii) (depends  on  machine)  is  untenable 

since  it  means  that  the  number  of  square  root  routines  depends 

on  the  hardware,  which,  from  a  portability  point  of  view  at  least, 

is  absurd.   (      footnote  at  end)  . 

If  we  take  approach  (i)  then  we  surely  discourage  the  accurate 

specification  of  precision  because  we  will  need  to  write  many  square 

root  routines  with  identical  bodies  (this  we  know  is  a  naive  view, 

since  the  algorithm  may  depend  on  the  precision,  but  let  it  pass 

for  now  -  if  it  really  bothers,  replace  sqrt  by  square  in  the 
preceeding  discussion) . 
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Thus  we  see  how  Ironman  arrived  at  answer  (ii) .   We  also 
have  the  analog  in  ALGOL-60  and  ALGOL-68  arrays  where  all  arrays 
(of  the  seune  number  of  dimensions)  are  one  type  and  one  need  not 
write  a  separate  s\im  procedure  for  each  array  length. 

What  about  implementation  of  (ii)?  Well  let  us  follow  the 
array  analog  further: 


a:  int  array  (10) 

a(3)  :=   0; 

efficient  code,  no 
dope  vector,  no  check 


Proc  b  (int  array  (*)a) 

a(3)   :=   0 

less  efficient  code, 
dope  vector  required 


Now  applying  the  same  principle  to  real  precisions  we  have; 


a,  b  :  real  (16) 

Proc   c(real  (*)  a,   b)  ; 

a   :=  a  +  b 

a   :=  a  +  b 

efficient  code,  no 

less  efficient  code. 

dope  vector,  no  check 

dope  vector  required 

The  "dope  vector"  for  a  real  is  simply  an  extra  tag  containing 
its  precision.   Normally  they  can  be  omitted  but  not  in  the  awkward 
cases.   The  type  system  is  intact,  but  the  thought  of  the  dynamic 
checks  involved  is  somewhat  unpleasant.   It  is  possible  to  use  the 
usual  incantation: 


"Oh  optimizer,  examine  the  program,  yea  even  unto  the  inter- 
procedural  level,  and  divine,  if  possible,  all  those  cases  where 
procedure  bodies  should  be  duplicated  ur.to  the  separate  precisions 
and  break  them  asunder  to  remove  the  evil  checks".  To  which  one 
might  ask,  does  anyone  know  of  an  ALGOL-60  compiler  which  will 
handle  the  array  case  well? 

Another  approach,  which  takes  cognizance  of  the  fact  that 
in  any  case  different  algorithms  are  required  for  different 
precisions,  was  suggested  earlier  by  . . . 

proc  sqrt  (real  (*)  x) ; 

if   prec(x)  £   a  return  ssqrt  (x) ; 

else  return  dsqrt  (x) ;   end; 

So  for  so  good,  but  how  about  the  definitions  of  ssqrt  and 
dsqrt? 

If  we  write 

proc  ssqrt  (real  (*)  x) 
the  dope  vector  will  follow  us  and  we  will  still  have  the  checks 
(unless  "on  optimizer  ...).   On  the  other  hand 

proc   ssqrt  (real  (9)   x) 

may  not  allow  us  to  use  sqrt  with  a  real  (8)  operand  unless  some 
sort  of  widening  is  automatic.   If  not,  explicit  conversions  will 
be  required  in  sqrt  itself. 

It  looks  like  the  Ironman  requirement  can  fly  with  a  little 
prodding  (a  lot  of  prodding  if  the  efficiency  requirement  is  being 
taken  seriously) ,  but  is  it  really  worth  the  effort?  We  are 
treading  on  thin  ice  here.   ALGOL-68  argued  through  these  issues 
some  time  ago,  so  did  PL/1.   Ironman  is  trying  to  imbed  the  PL/1 
approach  in  an  otherwise  clean  type  structure,  but  it  is  not 
clear  that  ALGOL-68  or  ALGOL-60  did  not  have  a  better  idea. 

Post-script.   If  the  Ironman  requirement  is  taken  seriously 
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Post-script.   If  the  Ironman  requirement  is  taken  seriously 


with  portability  in  mind,  then  the  exponent  access  routines  devised 
by  WG2.5  should  be  incorporated.   Writing  serious  portable  math 
software  without  them  is  dubious.   Using  these  primitives,  there 
is  a  much  better  chance  this  can  be  done. 


*  Footnote  for  page  2  ("absurd") . 

Bill  Waite  reacted  that  it  wouldn't  be  bad  to  have  a  variable 
number  of  square  root  procedures  if  they  were  generated  automatically, 
To  make  the  point  more  forcefully,  suppose  we  try  to  define  three 
procedures: 

proc  printr  (real  (8)  x)  :  "print  x  with  8  digits" 
proc  printr  (real  (12)  x) :  "print  x  with  12  digits" 
proc  printr  (real  (15)  x) :  "print  x  with  15  digits" 

Is  this  overloading  allowed?   "Yes"  and  "No"  are  tolerable  answers, 
but  "Maybe,  depends  on  machine"  is  clearly  unacceptable. 


PART  II 


DIALOG  ON  THE  EXCEPTION  MECHANISM  IN  GREEN  (WG2.4,  Twente,  6/9/78) 


CAST: 


R.  DEWAR 
C.  KOSTER 


COLOURLESS 


(Green) 


J.  ICHBIAH 

B.  KRIEG-BRUCKNER  \       GREEN 


(Dewar)    Is  this  legal  GREEN? 
Procedure   a; 

exception  gotox; 
begin   goto  x; 
end; 


raise   gotox; 


X: 


end; 


procedure   a 
exception   x_colon; 
begin 


end; 
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end; 


procedure   a 
exception   x_colon; 
begin 


end; 


begin 


end; 
begin 


ra;.se   x  colon; 


(Dewar)    I  don't  want  advice,  was  origir.al  legal?   YES  OR  NO! 

(Green)    No  goto  out  of         , 

procedures 

exceptionb 
(Dewar)  HAH  !  ! 

See  page  57,  section  9.2  (reference  manual)   Paragraph  3 

"Since  the  handler  acts  as  a  substitute  for  the  correisponding 
unit,  any  statement   that  is  legal  within  the  unit  may  be  used 
within  the  handler" 

(Green) 

The  handler  is  the  executer  after  the  body  has  died,  it  should 
do  what  the:  late  (and  iruch  regretted)  body  could  not  do  be;cause  of 
untimely  disappearence.    However!  (as  Fisher  would  say)  the 
executer  cannot  rescuscitate  the  body  even  by  a  goto  (Hell  of  course) 

(Dewar) 

I  agree  with  that  but  you  must  change  the  manual  on  this  point. 
How  do  I  do  this? 


procedure   x; 


I^^T-IT-V^a/I       KMl'^ 


to  check  here] 


exception    UNINITIALIZED 

begin 

y   :=  0;   goto   again; 
end 

again:     return   [some  giant  expression  using  y] 
end 

(Green)    Make  "again"  into  a  procedure! 

(Dewar)    Sorry,  can't  afford  the  time  to  call  a  procedure,  guess 
I'll  have  to  use  assembly  language!! 

(Green)    Use  inline 

(Dewar)    Sorry  can't  afford  space,  remember  it's  a  giant  expression! 

(Green)    Ok 

your  optimizing  compiler  detects  (in  the  non-inline  case), 
as  in  the  optimizing  BLISS  compiler,  that  the  call 
corresponding  to  goto  again  can  actually  be  transformed 
into  a  goto,  because  it  is  the  last  action  in  the  body  of 
the  exception. 
I  can  implement  a  call  to  a  local  procedure  with  3  instructions 
hence  be  consistent  in  the  definition  of  your  problem 

either    The  expression  is  large  and  you  contraidict  your- 
self when  you  say  that  you  cannot  afford  the  cost 
of  a  local  procedure  (not  much  more  than  a  goto) 

or        the  expression  is  small  and  you  can  afford  to 
replicate  it. 

(Dewar)         expression  is: 

else      [this  path  rare] 

[gigantic  expression  using  y] 


exception    UNINITIALIZED 
begin 


y   :=  0;   goto   again; 


end 


again:     return   [some  giant  expression  using  y] 
end 

(Green)    Make  "again"  into  a  procedure! 

(Dewar)    Sorry,  can't  afford  the  time  to  call  a  procedure,  guess 
I'll  have  to  use  assembly  language!! 

(Green)    Use  inline 

(Dewar)    Sorry  can't  afford  space,  remember  it's  a  giant  expression! 


(Green)    Ok 

your  optimizing  compiler  detects  (in  the  non-inline  case) , 
as  in  the  optimizing  BLISS  compiler,  that  the  call 
corresponding  to  goto  again  can  actually  be  transformed 
into  a  goto,  because  it  is  the  last  action  in  the  body  of 
the  exception. 
I  can  implement  a  call  to  a  local  procedure  with  3  instructions 
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of  a  local  procedure  (not  much  more  than  a  goto) 


or 


the  expression  is  small  and  you  can  afford  to 
replicate  it. 


(Dewar) 


expression  is: 


else      [this  path  rare] 

[gigantic  expression  usi.ng  y] 


(Green) 


procedure   P; 

F  :  function  . . . 
Rare  :   function 
exception  uninitialized; 
begin 

return  F; 
end; 

inline;   function   f  ; 
begin 

jj_  B   then 

return   y 

else 


return   G; 


end 


end; 
function  G; 


F  is  inline 
but  not  G 


(Dewar) 

At  this  stage  of  the  expression  I  want  to  remind  that  the 
original  program  omitted  the  exception  handler.   When  I  ran  it, 
I  found  this  bug  and  added  the  exception  handler  as  a  patch  to 
handle  an  exception.   It's  ani.oying  to  force  me  to  restructure 
the  program  and  does  not  add  to  its  clarity. 

Consider  the  following  conversation! 


Q.    How  do  I  get  up  these  stairs 
A.    Long  complicated  description 

(3rd  step  missing   etc., etc.) 
Q.    (after  exception) . 

But  I  ran  into  a  gare  at  the  bottom. 
A.    (Handler)  that  gate's  almost  always  open,  sorry,  just  open 

it  and  try  again. 


10 


(Green)    There  is  no  substitute  for  missing  intelligence  on 

A's  part! 
(Koster)   No,  in  some  cases  a  procedural  exception  handling 

is  preferable. 

(Green)    G,   Goos  made  the  prediction  that  DGD  1   would  be 
"extended"  in  this  respect  in  two  years  time. 

(Dewar)    Proposal  -  leave  the  manual  unchanged,  allow  the 
GOTO.  .  ^. 

What  if  world  war  3  is  in  1981?"""' 


COMMENT  (DEWAR) 

Why  not  make  rules  which  have  an  escape  hatch?   It  is 
annoying  to  have  to  work  out  subterfuges.   I  hate  gotos 
too,  but  I  hate  even  more  having  to  work  my  way  around  an 
issue  to  avoid  one.   Are  you  sure  the  language  is  complete? 
Well  it  really  doesn't  matter  if  I  have  the  means  to  get  out 
of  unusual  tricky  cases  without  using  assembly  language. 

COMMENT  (GREEN) 

Worth  considering.   I  need  to  think  about  it. 

COMMENT  (KOSTER) 

Obviously,  colourless  green  ideas  were  sleeping  furiously. 
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